## Introduction

[Product Backlog](/blog/scrum-artifacts-1-product-backlog/) is one of the artifacts in Scrum that requires a lot of attention and is crucial in building valuable products.  It is a list of everything that is needed in our product. 

As we all know, lists can be well organised, but they can also be really chaotic and don't bring too much value.  That’s why we want the list called [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) to be **healthy and well-maintained**. 

**How can you make sure your Product Backlog is healthy?** Let me write a few steps that can help you. 

## Use the Product Goal to guide you

As per [Scrum Guide](https://scrumguides.org/scrum-guide.html#product-backlog): 

>The Product Goal is the long-term objective for the Scrum Team.

It is the future state of the product that can guide you and your Scrum Team and help you plan how your [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) will be organised. 

I’ve seen Scrum Teams that worked without any Product Goal or any Product vision. What was the outcome? People were delivering features **without any objective in mind** and they didn’t really know **why they were developing** things.  Their Product Backlog was just a list, where everything was priority. People felt **demotivated** and you could notice their **lack of commitment.** 

**When everything is important, in reality nothing really matters.**

The first thing that you should always keep in mind whenever you build a  [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) or you support [PO](/blog/scrum-roles-2-product-owner/) & [Developers](/blog/scrum-roles-1-development-team/) in creating it, is a **clear vision of the product**. 

Make sure your [Product Owner](https://letsscrumit.com/scrum-roles-2-product-owner/)  specifies what is the **Product Goal** and use it whenever any new item is added to the [Product Backlog](/blog/scrum-artifacts-1-product-backlog/).

**Product Goal** can help you in ordering items and deciding what are the top priorities and what you should focus on. 

![goal](img/goal.jpg)

## Make sure the Product Backlog is a single source of truth

[Product Backlog](/blog/scrum-artifacts-1-product-backlog/) should always be a **single source of truth** in terms of what we want to **improve in the product**.  It’s not a healthy situation when other sources are used to determine what needs to be improved, built in the product.  We always want to keep [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) **up to date** and include any new information or changes that were discussed.

This is the only way to be **transparent** and make sure that everyone in the Scrum Team can see **what we are building and why**. 

Using emails, calls or private messages to cover changes related to product without updating  [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) can be the cause of **misunderstandings** within the team. Especially if these discussions are not with [Product Owner](/blog/scrum-roles-2-product-owner/), but other stakeholders. 

That’s one of the common situations, when [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) can start growing without keeping in mind the Product Goal. 

## Refine it regularly 

To keep the [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) healthy, we need to have **regular refinements**. That should also include **clean up of the Product Backlog** and removing unnecessary Product Backlog Items. 

As per [Scrum Guide](https://scrumguides.org/scrum-guide.html#product-backlog) 

>  Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size.

You need to continuously refine your [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) and **add more details, adjust based on the current situation**. 

[Product Backlog](/blog/scrum-artifacts-1-product-backlog/) is a **living artifact** which means that it will keep **changing**. It’s not enough to create it once (like the old list of requirements in Waterfall) and use it as a reference. You want to update it **based on the feedback** from your stakeholders and you want to have a [Product Owner](/blog/scrum-roles-2-product-owner/) & [Developers](/blog/scrum-roles-1-development-team/) involved in refinement. 

One of the good practices to keep the [Product Backlog](https://letsscrumit.com/scrum-artifacts-1-product-backlog/) healthy is **deleting anything in the Backlog that is older than 6 months**. Let's be honest, you will most likely not work on those items. Even if they would be important, you don't need to worry - they will come up in feedback from stakeholders or users. 

![Refinement](img/refine.jpg)

## Keep the top of the Product Backlog ready for the Sprint

To clarify, by ready I mean clear enough, so that [Developers](/blog/scrum-roles-1-development-team/) can start working on it in the upcoming Sprint. 

We want to avoid situations when [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) is chaotic and **never ready** for the [Sprint Planning](/blog/scrum-events-2-sprint-planning/), because it will stop your Scrum Team from **delivering value**. 

That’s why you need to refine [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) on a **regular basis**. This will help you to have enough items ready for the following Sprint. 

Try to have enough Product Backlog items ready for the next **2-3 Sprints**. You don't want to refine everything, because things can change. But in the same time you want to have the **top of the [Product Backlog](https://letsscrumit.com/scrum-artifacts-1-product-backlog/) ready**. 

## Use INVEST when creating user stories & consistent format for others

Do you know the acronym **INVEST** used as a guidance in creating user stories? 
* **I - Independent** - you want to deliver value from one individual story and be able to work on it separately without working on another user story.  

* **N - negotiable** - user story can change and [Developers](/blog/scrum-roles-1-development-team/) can update it with [Product Owner](/blog/scrum-roles-2-product-owner/) once they recognize it is required.  

* **V - valuable** - every story should deliver value to the user and somehow fulfil their needs.  

* **E - estimable** - you want to be able to estimate the story. If it is not possible, the user story should be divided into smaller pieces.  

* **S - small** - user story should be small enough to develop it within the Sprint. - **T - testable** - each user story needs to be testable and have a clear acceptance criteria to verify it. 

How does INVEST help in the whole [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) health? When your user stories are meaningful and well-described,  it is easier to manage and understand the [Product Backlog](https://letsscrumit.com/scrum-artifacts-1-product-backlog/). 

Of course user stories are not the only Product Backlog type. Make sure that you have a **consistent format** for all items in your [Product Backlog](https://letsscrumit.com/scrum-artifacts-1-product-backlog/). You will avoid **confusion and misunderstandings**.

## Visualise the Product Backlog

Healthy [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) means **transparent** [Product Backlog](https://letsscrumit.com/scrum-artifacts-1-product-backlog/). 

Visual representation of the [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) can help to make it more **visible and clear** for all Scrum Team members and stakeholders. 

What are the ways to visualise it?  
* When you start creating [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) you can use [**User Story Mapping**](https://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909). 

* To show your vision of the product, use a **roadmap**. If you add dates there - remember that these are **not set in stone** and you should adjust the roadmap based on the progress made by your team.  

* Utilise options that your **tools** can offer you to make the view of the [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) more visual e.g. use **labels, different colours for epics, quick filters** and anything else that you can use in the tool that you use on a daily basis to manage your Product Backlog. 

![Visual](img/roadmap.jpg)

## Summary

Keeping your [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) **healthy requires attention to details, but also a high level vision**. 
* You want to have a **clear Product Goal** that will guide you in creating and ordering new items. 

* [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) should remain the **single source of truth** to keep transparency.  

* Keep **refining** your [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) with your Scrum Team and remove unnecessary items.  

* **Top** of the [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) should be **ready for the upcoming Sprint**. 

* The content of the Product Backlog can be easily managed by including the **INVEST** rule in creating user stories and having **consistent format** for other PBIs. 

* To help in visibility of the [Product Backlog](/blog/scrum-artifacts-1-product-backlog/), **visualise it** and make it easier for them to understand. 

These are one of the basic rules that can help you to keep your [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) healthy. 

**What are the other items that you would add to this list?** Is there anything more that helps you to keep your [Product Backlog](/blog/scrum-artifacts-1-product-backlog/)  well-maintained and healthy? 


Are you using the full potential of your Product Backlog? Is it chaotic or well-maintained and ordered? Find out how you can keep it healthy to help your team build high-quality product.

How to keep Product Backlog healthy?

## Introduction

As I mentioned in my last [post](https://letsscrumit.com/scrum-roles-1-development-team/), Scrum Team consists of the [Development Team](https://letsscrumit.com/scrum-roles-1-development-team/), Product Owner and Scrum Master.  I’ve already described the [Development Team](https://letsscrumit.com/scrum-roles-1-development-team/) and today I would like to tell you more about the **Product Owner**. 

## Who is the Product Owner

Let’s check what Scrum Guide says about it: > The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

This is important information - Product Owner is **one individual**, not a group of people. Why?  The reason is simple - multiple people mean multiple decisions, visions and increased complexity. 

![Product-Owner](img/productowner.jpeg)

## What is the Product Owner responsible for?

Based on the Scrum Guide:

> The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

Ok, you may ask now - "What does it mean maximizing value?" 

First of all, a Product Owner needs to have a deep understanding of the product. Based on the knowledge about the product, he or she can decide what direction of the development will be the most valuable. It can be done based on the market situation, company strategy or analysis of the customer needs. As it was described in the Scrum Guide, it can vary across companies. 

The simple example from real life: the Product Owner receives the request from the higher management in the company that they want to implement some additional product functionality urgently. 

Before the Product Owner makes any decisions, he or she needs to analyze all implications related to technical aspects, impediments, customer needs etc.  Based on the analysis the Product Owner decides if the new action will be valuable for the product or not. 

## Product Owner & Product Backlog

As we can read in the Scrum Guide:

> The Product Owner is the sole person responsible for managing the Product Backlog. 

If you don’t know the Scrum yet, you may ask - "What is the Product Backlog?"  It is a list of everything that is required, needed in the product. 
The Product Owner is responsible for creating this list of work items called "Product Backlog items" and managing it. 

![Product-backlog](img/backlog.jpg)

**How can the Product Owner manage the Product Backlog?**
* All Product Backlog items should be clear and understandable for everyone in the Development Team. The most priority items should be fully explained to allow the team to plan their work accordingly.

* Product Backlog should be visible to everyone in the Scrum Team to make sure all requirements and vision of the product are transparent.

* Items need to be ordered by PO based on the business goals and strategy. The most important and priority work should be on the top of the Product Backlog.

* During management of the Product Backlog PO should consider work required from the Development Team and decide how to optimize the value of their work.

Some of the above responsibilities can be done by different people (selected by PO), but the Product Owner remains accountable in terms of the Product Backlog management.

## Product Owner - other responsibilities

The Product Owner is the only person who has authority to cancel the [Sprint](https://letsscrumit.com/scrum-events-1-the-sprint/). It is a really rare case, but this decision can be made by the Product Owner due to technology or market changes.

The Product Owner is also the main link between business and the Development Team. She or he needs to fully understand business needs and clearly express them to the team. 

In Scrum there is one event facilitated mostly by the Product Owner - [Sprint Review](https://letsscrumit.com/scrum-events-4-sprint-review/): 
* All key stakeholders need to be invited by the PO to the meeting. He or she needs to explain what Product Backlog items were "Done" during the Sprint and what is the current status of the Product Backlog.

* Together with all stakeholders and other members of the Scrum Team, the Product Owner analyzes the marketplace, budget and potential timeline.

  
![Stakeholders](img/stakeholders.jpg)

## Product Owner & Sprint Backlog

The Product Owner is responsible for Product Backlog, but what about **Sprint Backlog**?  Sprint Backlog is created during [Sprint Planning](https://letsscrumit.com/scrum-events-2-sprint-planning/) and includes items selected from the Product Backlog for the new [Sprint](https://letsscrumit.com/scrum-events-1-the-sprint/).

The difference between **Product Backlog** and **Sprint Backlog** is that the first one is managed and can be changed by the Product Owner, while the other one belongs solely to the [Development Team](https://letsscrumit.com/scrum-roles-1-development-team/).  It means that the Product Owner cannot update it in the Sprint or add anything. The Development Team can change it and renegotiate selected items with the Product Owner if it’s needed. 

Moreover, the Product Owner plays the important role in **clarification of the Product Backlog Items**. If the Development Team has any concerns related to items selected for the Sprint, the Product Owner should help them and explain all unclear details.

## Summary

To sum up the Product Owner’s role, it is **one person** who makes sure that all the actions within the Sprint are **maximizing value of the product**. 

The Product Owner needs to be the **link between all stakeholders and the Development Team**. She or he should know deeply the product, business needs and marketplace in order to achieve the best results during the product development process. 

The main responsibility of the Product Owner is the **Product Backlog management** including ordering, clarification of items and optimizing the Development Team’s work. 

Who is the Product Owner? What are her or his responsibilities? Read this post to find out more about this Scrum Role.

2 posts tagged with #product owner